The following terms are commonly used in test and measurement systems and will be used herein as defined.
Reporting Name—
A reporting name is a name used to uniquely identify a test or measurement value.
Condition or Measurement Condition—
A condition or measurement condition is a stimuli or set up value that is required to uniquely identify the conditions under which a test or measurement value is obtained. The condition is used to help identify comparable measurement values. For example, a power measurement on a device under test can be dependent upon the frequency of the measurement. In a pass-fail test, the specification for a system at 100 MHz can be significantly different from that at 150 MHz. In this case, aggregation of the power measurement for statistical analysis should only occur at an equivalent frequency. Often such information is encoded into the reporting name, e.g., “Power@200 Mhz”.
Publisher—
A publisher is a piece of code that originally acquires information about the device under test and provides it to other storage and/or analysis programs via a text file or data base entry.
Test Program—
A test program is any piece of code written in any language whose purpose is to collect information about a device under test (DUT) by stimulating the device under test and measuring outputs or reactions of the device under test.
Test Plan—
A test plan is the information that a test executive uses to direct the testing of a device under test. This is the data driven alternative to writing a test program. Test executives typically provide for more structure and less flexibility while improving consistency and re-usability of testing algorithms. Examples include TestExecSL from Agilent Technologies and TestStand from National Instruments (TestExecSL is a trademark of Agilent Technologies and TestStand is a trademark of National Instruments Corporation).
Results Subscriber—
A results subscriber is a piece of program code that receives published records and transforms them into the style and format desired by the user or test organization. Subscribers are also referred to as listeners.
Previous data logging techniques often require that the publisher of the data, usually a test and measurement program or test executive, decide on the record format and its structure at the time the measurement is taken. Interactive graphical presentations are controlled directly from the publishing program as well. The knowledge required to publish the data leads to less reusable and more complex tests or measurement code. Existing alternatives to this up-front association require a post processor. However, the post processor becomes just as complex when handling conditions.
In typical test programs, the publisher decides what information is to be collected and how to organize it effectively. Condition information is often encoded into the reporting name. A “Power” measurement will encode the condition. For example, “Power@150 MHz” and “Power@200 MHz” will be logged with the separate names. In this way, two unlike power measurements are uniquely named and, therefore, separable for statistical analysis purposes. A histogram combining the two power measurements would be of little use since the expected values are different for each unique condition. Encoding the condition in the name requires that the publisher of the data have access to the condition information when the measurement value is published. This creates problems in many test and measurement programs.
The condition may have been set up earlier in the program and applied for several tests or measurements. Factoring out common stimuli improves performance of the program (or test plan in a test executive). However, if the test is still required to store this setup information in the reporting name, it must be passed into the test. This increases the complexity of the test and measurements. The test must have knowledge of the kind and format of the stimuli information. The stimuli information may be passed in as extra parameter or some external data passing scheme. The stimuli information, however, is not used in the measurement except for the purpose of data logging. The test or measurement then becomes no longer highly re-usable, as the stimuli information is now strongly coupled to the test or measurement. Changes to the number and type of conditions now require changes to the measurement or test.
The stimuli data which is passed into a test is called driving data. Holding driving data in an array or table is an improvement to encoding the condition in the name. The measurement values are combined with the data in the driving data table as it is published. A given test organization can then change the values of the driving data dynamically according to changing needs. However, changes are limited in scope and a coupling still exists with the test or measurement since the test must fill up the driving data table with measurement values and publish it.
Another solution is to let outer loops of the test program or test plan publish the conditions as they occur. The tests or measurements that follow are now independent of the condition. The nested test now has no knowledge of the condition or of its existence. The same test or measurement can be reused in another loop or part of the test program with no modification required. The number and kind of conditions can be modified with no changes to the measurement or test. The stimuli data can be changed based on the changing needs of the testing organization.
However, the association of the test and measurement with the condition must be made at some later point in time. This creates significant set of new problems. Some kind of post-processing program or algorithm is needed to re-associate the conditions with the measurements. While some test systems include a post processor, the job of association becomes complex quickly and is rarely done. For example, the organization may stuff the data into a relational database and use time stamps to associate the conditions with the measurements. Using SQL, the data base expert can extract only those measurements with common conditions. However, the queries on the database become complex. Often, the writer of those queries needs detailed knowledge of the test program that generated the results to make the association. Once the proper association is made, the data resulting from those queries are then analyzed statistically and, optionally, presented graphically. This process is time consuming and does not allow for quick interactive graphical displays of the data as it is being collected.